Windows Server 2003 Security Configuration (part 1) - Windows Server 2003 Security Settings

Security Configuration Overview

Windows Server 2003 provides numerous settings to secure hardware devices, operating system components, and features. To plan a security configuration for your enterprise, you must understand and evaluate the configuration settings available to you and determine what constitutes good security. Then, you must design a security implementation that applies a standard, baseline security policy for all systems, and then modifies that baseline for particular systems based on their roles.

Once you have designed the security configuration, you must be able to implement that configuration. In the past, many tools and low-level Registry adjustments were necessary to fulfill a security policy. Settings can be configured using a variety of tools on an individual server, but of course a manual approach to security configuration is both inefficient—particularly in environments with several servers—and difficult to maintain.

Group Policy

To increase the efficiency of applying a security configuration, Windows Server 2003 supports the implementation and maintenance of security configuration through Group Policy Objects (GPOs). GPOs can be linked to sites, domains, and organizational (OUs) in Active Directory and can drive the configuration of users and computers within the scope of the GPO link. For example, a GPO could be configured with the security settings for Web servers in your environment, and then linked to an OU in which the servers’ computer accounts exist. Those Web servers would then be secured based on the policies in the GPO. If administrators were to change the settings on an individual server, Group Policy refresh would reset the settings to adhere to the security policies of the GPO. GPOs thus allow you to deploy security settings more efficiently and to be confident that the settings are being maintained over time.

Security Templates

Windows Server 2003 also supports deploying security settings by using security templates, which are text files that, when applied to a server, determine the server’s security configuration. Security templates are useful in several scenarios, including situations in which a server is not subject to Group Policy. Security templates can also be used to export the security configuration from one server and apply that configuration to another server. It is even possible to deploy a security template via Group Policy.

Security Configuration Tools

The primary tools used to centrally plan, implement, maintain, and troubleshoot security configuration include: Group Policy Object Editor, Active Directory Users And Computers or the Group Policy Management Console to administer GPO properties and links, the Security Configuration And Analysis and Security Templates snap-ins that support the management and deployment of security templates, and the Secedit.exe command.

Windows Server 2003 Security Settings

In this section, you will learn about many of the security settings that can be configured for a server. Keep in mind that each of these settings can be managed on an individual server by using administrative snap-ins, or they can be deployed and maintained on one or more servers through security templates or Group Policy.

Audit Policies

Auditing is an important part of a secure baseline installation because it enables you to gather information about the computer’s activities as they happen. If a security incident occurs, you want to have as much information about the event as possible, and auditing specific system components makes the information available. The problem with auditing is that it can easily give you an embarrassment of riches. You can’t have too much information when a security breach occurs, but most of the time your servers will be operating normally. If you configure the system to audit too many events, you can end up with enormous log files consuming large amounts of disk space and making it difficult to find the information that is most pertinent. The object of an audit configuration is to achieve a balance between enough auditing information and too much.

When you configure Windows Server 2003 to audit events, the system creates entries in the Security log that you can see in the Event Viewer console. (See Figure 1). Each audit entry contains the action that triggered the event, the user and computer objects involved, and the event’s date and time.

The following audit policies are available:

• Audit Account Logon Events Each instance of a user logging on to a computer. This policy is intended primarily for domain controllers, which authenticate users as they log on to other computers. There is typically no need to activate this policy on a member server.

• Audit Account Management Each account management event that occurs on the computer, such as creating, modifying, or deleting a user object, or changing a password. On a member server, this policy applies only to local account management events. If your network relies on Active Directory for its accounts, administrators seldom have to work with local accounts. However, activating this policy can detect unauthorized changes to accounts in the local directory—the Security Accounts Manager (SAM)—of the local computer.

• Audit Directory Service Access A user accessing an Active Directory object that has its own system access control list (SACL). This policy applies only to domain controllers, so there is no need for you to enable it on your member servers.

• Audit Logon Events Users logging on to or off the local computer when the local computer or a domain controller authenticates them. You use this policy to track user logons and logoffs, enabling you to determine which user was accessing the computer when a specific event occurred.

• Audit Object Access A user accesses an operating system element such as a file, folder, or registry key. To audit elements like these, you must enable this policy and you must enable auditing on the resource you want to monitor. For example, to audit user accesses of a particular file or folder, you display its Properties dialog box with the Security tab active, navigate to the Auditing tab in the Advanced Security Settings dialog box for that file or folder (as shown in Figure 9-2), and then add the users or groups whose access to that file or folder you want to audit.

  Figure 2. The Advanced Security Settings dialog box

  

• Audit Policy Change Someone changes one of the computer’s audit policies, user rights assignments, or trust policies. This policy is a useful tool for tracking changes administrators make to the computer’s security configuration. For example, an administrator might disable a policy temporarily to perform a specific task and then forget to re-enable it. Auditing enables you to track the administrator’s activities and notice the oversight.

• Audit Privilege Use A user exercises a user right. By default, Windows Server 2003 excludes the following user rights from auditing because they tend to generate large numbers of log entries: Bypass Traverse Checking, Debug Programs, Create A Token Object, Replace Process Level Token, Generate Security Audits, Back Up Files And Directories, and Restore Files And Directories.

  Tip

  It is possible to enable auditing of the user rights listed here by adding the following key to the registry in the Microsoft Windows operating system: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FullPrivilegeAuditing=3,1. However, if you do this, you should be prepared to deal with the large number of log entries that auditing these user rights generates by increasing the maximum size of the logs and having a policy for frequent evaluation and clearance of the logs.

  
  

• Audit Process Tracking The computer experiences an event such as a program activation or a process exit. While this policy gathers information that is valuable when analyzing a security incident, it also generates a large number of log entries.

• Audit System Events Someone shuts down or restarts the computer or an event occurs that affects system security or the security log.

When you enable one of these audit policies, you can select three possible values, which determine the conditions for creating an audit entry, as follows:

• Successes only (select the Success check box) Only when the specified action completes successfully

• Failure only (select the Failure check box) Only when the specified action fails

• Successes and Failures (select both the Success and Failure check boxes) Whether the specified action succeeds or fails

• No auditing (clear both the Success and Failure check boxes) No audit entries for the specified actions under any circumstances

For security purposes, auditing failures can often be more valuable than auditing successes. For example, the default Audit Account Logon Events policy value for domain controllers is to audit successful logons only. This enables you to determine who was logged on to the network at any time. However, if an unauthorized user attempts to penetrate an administrative account by guessing passwords, the audit log would not contain any evidence of these attempts. Selecting the Failure check box for the Audit Account Logon Events policy gives you information about the failed logon attempts as well as the successful ones.

Event Log Policies

The Event Log is an essential tool for Windows Server 2003 administrators, and the Event Log policies control various aspects of the log’s performance, including the maximum size of the logs, who has access to them, and how the logs behave when they reach their maximum size.

Each log—application, security, and system—has four policies:

• Maximum log size Specifies the maximum size the system permits, in kilobytes. Values must be in 64 KB increments, and the maximum value is 4,194,240 (4 gigabytes).

• Prevent local guests group from accessing log Specifies whether members of the local Guests group on the computer are permitted to view the log file.

• Retain log Specifies the number of days for which the log should retain information.

• Retention method for log Specifies the behavior of the log when it reaches its maximum size, using the following options:

  • Overwrite Events By Days— The log retains the number of days of entries specified by the retain log policy. Once the log grows to the specified number of days, the system erases the oldest day’s entries each day.

  • Overwrite Events As Needed— The log erases the oldest individual entries as needed once the log file has reached the size specified in the maximum log size policy.

  • Do Not Overwrite Events (Clear Log Manually)— The system stops creating new entries when the log reaches the size specified in the maximum log size policy.

Creating an event logging configuration usually requires some experimentation. The best way to proceed is to configure the events and resources you want to audit, and then let the logs accrue for several days. Calculate the average number of entries for each log per day and then decide how many days of history you want to retain. This enables you to determine a suitable maximum size for your logs.

Before setting the retain log and retention method for log policies, you should decide how often someone is going to review the logs and clear or archive them when necessary. If it is essential to retain all log information, you can specify a maximum size for the log and then enable the Security Options policy, Audit: Shut Down System Immediately If Unable To Log Security Audits, which forces you to manage the logs regularly.

System Services Policies

Services are programs that run continuously in the background, waiting for other applications to call on them. For this reason, services present potential surfaces for attack, which intruders might be able to exploit. Windows Server 2003 installs a number of services with the operating system, and configures quite a few with the Automatic startup type, so that these services load automatically when the system starts. Because servers often serve designated roles, it is possible using System Services policies to disable services that a server does not need to perform its specific function.

Table 1 describes the services that Windows Server 2003 typically installs on a member server. The Automatic column contains the services that Windows Server 2003 requires for basic system management and communications. The Manual column contains services that do not have to be running all the time, but which must be available so that other processes can activate them. The Disabled column contains services that the typical member server does not need, and which you can deactivate by setting its startup parameter to Disabled, unless the computer has a specific need for them.

Security Options Policies

Security Options policies allow you to secure specific server components and features. Almost all these policies are undefined in a default member server installation, but you can activate them and use them to secure servers against a wide variety of accidents and threats.

Some of the most useful Security Options policies are as follows:

• Accounts: Administrator Account Status Enables or disables the computer’s local Administrator account.

• Accounts: Guest Account Status Enables or disables the computer’s local Guest account.

• Accounts: Rename Administrator Account Specifies an alternative name for the security identifier (SID) associated with the local Administrator account.

• Accounts: Rename Guest Account Specifies an alternative name for the SID associated with the local Guest account.

• Audit: Audit The Use Of Backup And Restore Privilege Causes the computer to audit all user privileges when the Audit Privilege Use policy is enabled, including all file system backups and restores.

• Audit: Shut Down System Immediately If Unable To Log Security Audits Causes the computer to shut down if the system is unable to add auditing entries to the security log because the log has reached its maximum size.

• Devices: Allowed To Format And Eject Removable Media Specifies which local groups are permitted to format and eject removable NTFS file system media.

• Devices: Restrict CD-ROM Access To Locally Logged-on User Only Prevents network users from accessing the computer’s CD-ROM drives.

• Devices: Restrict Floppy Access To Locally Logged-on User Only Prevents network users from accessing the computer’s floppy disk drive.

• Domain Member: Maximum Machine Account Password Age Specifies how often the system changes its computer account password.

• Interactive Logon: Do Not Require CTRL+ALT+DEL Select the Disable option to protect users against Trojan horse attacks that attempt to intercept users’ passwords.

• Interactive Logon: Require Domain Controller Authentication To Unlock Workstation Prevents unlocking the computer using cached credentials. The computer must be able to use a domain controller to authenticate the user attempting to unlock the system for the process to succeed.

• Microsoft Network Client: Digitally Sign Communications (Always) The computer requires packet signatures for all Server Message Block (SMB) client communications.

• Microsoft Network Server: Digitally Sign Communications (Always) The computer requires packet signatures for all Server Message Block (SMB) server communications.

• Network Access: Do Not Allow Anonymous Enumeration Of SAM Accounts And Shares Prevents anonymous users from determining the names of local user accounts and shares. This prevents potential intruders from gathering information about the computer without being authenticated.

• Network Access: Remotely Accessible Registry Paths And Subpaths Specifies which registry paths and subpaths qualified users can access over the network.

• Network Access: Shares That Can Be Accessed Anonymously Specifies which shares anonymous users are permitted to access.

• Network Security: Force Logoff When Logon Hours Expire Causes the computer to terminate existing local user connections when they reach the end of their specified logon time.

• Shutdown: Allow System To Be Shut Down Without Having To Log On Activates the Shut Down button in the Log On To Windows dialog box.

Restricted Groups Policies

In baseline and server role security configurations, it is important to manage the membership of local groups on domain computers, particularly built-in and local groups that have built-in and default user rights, such as the Administrators, Power Users, Backup Operators, Print Operators, Server Operators, and Account Operators groups.

To use restricted group policies, simply add a policy with the name of a group, and then configure its members. You can also configure the Members Of property of the group—ensuring that it is nested in appropriate groups. When security policies are applied or refreshed, the restricted group policy will ensure that the Members and Members Of properties remain consistent with organizational security policy.

Registry Policies

Registry policies allow you to set the ACL of registry keys. Rather than set ACLs of registry keys manually, registry policies provide centralized administration and maintenance of a secured registry and make it easy to reset registry key ACLs should they need to be changed.

File System

File system policies, like registry policies, provide centralized management of ACLs on files and folders. When you add a policy for a file or folder and configure its ACL, any system that contains a file or folder that matches the policy will enforce the ACL specified by the policy.

User Rights

User rights policies determine user logon rights and privileges. Logon rights include the right to log on locally or through Terminal Services or over the network. Privileges include the ability to back up or restore files, shut down the system, or run as a service. User rights policies are described in the section regarding domain controller security, later in this lesson.

Account Policies

Account policies include policies that determine password requirements, account lockout, and Kerberos settings. Password policies include minimum length, history, complexity, and how frequently passwords must be changed. Account lockout policies determine the number of failed logon attempts within a specified time frame that trigger account lockout, as well as the policy to reset locked out accounts. Kerberos policies configure Kerberos ticket lifetime and renewal time, whether user logon restrictions are honored, and clock skew time.